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I think its fitting that this meeting is being held on what is known 
today as "Earth Day". Those of you who don't have children in grade 
school probably don't realize that today across the country, there 

is an anti-pollution campaign. All the kids are out cleaning up the 
rubbish, and people are talking about getting pollution out of the 
air and the rest of our environment. So our objective today is to 
clear the air with you as well. I think that for some of the previous 
CUBE Meetings a more symbolic event might have been a total eclipse 
of the Sun, but today, realizing that the interest in the B6500 is at 
a peak right now during this CUBE Meeting, we've made a special 
effort for full coverage during the next couple of days. My session 
will cover. the status report on the B6500, and then following that 

we have Byron Harrington, Ben Dent and Wayne Nelson, and we wiil 
handle any questions that you have. : 


For the balance of the meeting, then, we have people from Pasadena, 
from Sales Tech Services in Detroit, and from the Management 
Systems Development Group. 


All these people have been chosen to give us coverage of all the 
subject areas that we feel will come up during the CUBE Meeting 
regarding the B6500. 


I think the emphasis, as you can see, has been put on total coverage 

of the B6500, and our interest in being here is to keep those commu- 
nication channels open between you and us, and to answer your questions 
when you ask them and not to put you off unnecessarily. It's 

always a difficult challenge to do this. The subject area is very 
broad, and no one person can handle ail the answers, but we've made 

a special attempt at this meeting to give you full coverage. 


Let's start now with the status report on the B6500 today, covering 
installed systems first. This week we are currently preparing the 
delivery of B6500 numbers fifteen and sixteen. I think it's 
surprising to many people that we have delivered that many systems 
----fourteen prior to this week. The next two will be going to our 
Defense & Space Facility in Paoli, Pennsylvania and to London,: and 
will include the first Data Comm Processor shipment. The London 
system will be for our use overseas in support of the many large 
systems that have been sold in Europe. 


Pasadena Engineering has four of the previously installed machines. 
Manufacturing is using one for peripheral control testing, the other 
two are being used by the Systems Engineering Groups, both hardware 


and software, in Pasadena. We'll talk more about the way in which 
they are used there later. The first system that was shipped from 
Pasadena went to Sales Tech Services in Detroit. Then the Western 


Region system was shipped to the Wells Fargo site in San Francisco. 
This gives us a total of eight in-house machines, and, as you will 
recall from previous CUBE Meetings, we told you that the early 
emphasis would be on getting systems installed within Burroughs, not 
only for our own development work, but also to permit us to go through 
the shake-down period in our facilities rather than in customer 
offices. I think this is working out very well. 


We have now shipped systems to customers in all three of our operating 
divisions. In the International Division there is the large dual- 
processor system at Barclays Bank, and two systems at Midland Bank, 
both in England. Mitsubishi 0il in Japan took delivery of a system 
last month. For our Defense & Space organization, we have shipped 
systems to the Illiac IV Project, and to Ft. Meade, Maryland. That 
system is being installed right now. For the Business Machines Group, 
which is our domestic operation, we have just made our most recent 
deliveries to the two University of California Campuses, one at Davis, 
and one at San Diego. 


May will be a particularly big and significant month for customer 
shipments of B6500's. We will be shipping three machines that month, 
all large configurations. They will go to General Mills, the Illinois 
Secretary of State and the NYSIIS Organization (New York State 
Investigation & Identification System). We are shipping now at the 
rate of three systems per month. We began this rate of shipment in 
February, and we are still on schedule. The shipment picture looks 
very encouraging. Of course, when we meet these shipments in May, 

we will pass a significant milestone, three customer systems shipped 
on schedule in the month of May, and we will continue that rate of 
shipment through mid-year. At that time, we will gradually build up 
the shipping rate until we will be delivering at the rate of six 
systems per month at the end of the year. 


I think it's encouraging to look at the way in which currently 
installed B6500's are being used. The Detroit Facility system, the 

one with which I am most personally familiar, logs from eighteen to 
twenty-two hours of systems use daily. The up-time has been very 
good---excellent, in fact. Down-time has been associated primarily 
with the installation of engineering changes as they come in---a card 
change here, a wire change there. The up-time has been very good, as 
many customers who have come in to use the system for debugging 
purposes, for conversion work and benchmark demonstrations will attest. 
The same is true of the Western Region system at San Francisco. It's 
also consistantly being logged for seventeen to twenty-one hours a day 
during the week. The actual usage probably isn't that great, but that's 
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using the machine. The system there in San Francisco, as well as the 
one in Detroit, are both being used extensively for training of our 
own tech people and the field engineers, as well as customer training. 
We will discuss training more in a moment. 


There is a lot of encouragement also to be derived from the way the 
systems, as they are being installed, come up in the customer office. 
For example, let's take the last two systems to be delivered, the one 
to the University of California - Davis, and the other to the University 
of California at San Diego. Both systems were shipped about a day 
apart, April 7 and April 8". Within four days at San Diego they had 
power on the system, and they started running engineering tests on the 
seventeenth - about nine days after delivery. That same day, the 

power was turned on at the Davis system, which was last Friday. If 
things proceed as well as they have been at San Diego, and at Davis 

as well, they will be trying to load the systems tape and execute under 
control of the MCP this week. That's really two weeks after delivery, 
which is about four to six weeks ahead of our planned schedule for 
installation. This attests not only to the soundness of the hardware, 
but also to the skills and abilities of our field engineering people 
making these installations and supporting them in the field. This is 
very good progress, and we are all encouraged by it. 


As I mentioned, field engineering now schedules from four to six 
weeks for getting these systems operational and turned over for 
productive use. We expect that this will be reduced to a three week 
period as field installations increase and as our experience grows 
in the procedures involved in getting them in and checking power and 
so forth. 


To assist in this check-out, we scheduled the field engineers into 
the plant prior to the shipment of the equipment. For example, for 
the May shipments, the field engineers are in Pasadena now riding 

out the systems that they will be responsible for installing. In 

the future, we plan to get these people on site in the plant at the 
time their configuration is being assembled. This would meam some 
ninety days prior to shipment. The field cngineers will then have 
been trained not only on the B6500 as a product, but also on the 
particular B6500 that they will be responsible for maintaining after 
it's in. This not only gives them additional experience, but provides 
a wealth of knowledge gained by working shoulder to shoulder with the 
engineering experts on the system, and with the quality assurance 
people who make the final check-out before the machine is delivered. 


In terms of the B6500 performance level thus far, it's hard to 

cover this subject in one gross statement. It is, of course, a 
function of the features currently available on the system tape, 
which determines how much work we are able to handle from one day 

to the next. User experience and our own experience has shown that 
roughly seventy to ninety percent of all the programs that have been 
brought in to be compiled and executed on the B6500 do, in fact, 
compile and execute. Now this is based upon the experiences that 


we have had in taking user programs and programs that customers and 
prospects have brought to us. I'm talking now about B5500 programs 
and whether they will compile and execute on the B6500. We've had 
some fifty or sixty FORTRAN jobs, for example, from the University 
of Galifornia at Davis, and C. F. Braun has given us some ALGOL and 
COBOL jobs. The University of Wisconsin recently took some forty- 
five programs - I believe most of those were ALGOL - with some COBOL 
and FORTRAN, and forty-two out of the forty-five ran during a two or 
three day session at the San Francisco installation. That's a pretty 
good indication of the status of the system running with the current 
MCP. We'll talk in a moment about the system tape that will be 
shipped within a week from now. 


The range of performance, in terms of speed and throughput versus 
the B5500, seems to cover a range of from two-to-one over the B5500 
to five-to-one. Again, this is purely a function of the programs 
you're’ running, and the peripheral equipment being used, and is 
primarily comparing the serial processing runs of jobs that we've 
taken from the B5500. We have done very effective multi-programing. 
It's always interesting to see the reaction of prospects that are 
new tc Burroughs large systems when we say we want to bring them in 
for a demonstration of the B6500, bring a ray of sunshine into their 
otherwise dismal 360 existence and show them a computer operation. 
We explain to them and apologize for the fact that this is still at 
the tail end of the development phase, so we won't be able to show 
them a lot. Then they observe ten jobs in the mix. Well, maybe at 
that point the double precision isn't working, but they're not too 
concerned with that after they see the level of development from which 
we're starting on a system like the B6500. 


People frequently ask what the level of marketing activity is now 

on the B6500 because it's sort of a wait-and-see-period. It's still 
amazingly high. The interest, of course, is maintained because they 
see the tremendous potential of that system. The frustration, of 
course, is just the waiting for the point at which we have a complete, 
operating, functioning B6500. It's impressive, and it's significant 
to know that running with user programs to get timing and performance 
comparisons, we've run with two, three, five, up to ten jobs in the 
mix at one time. For test purposes in Pasadena, just to see wheiier 

' the MCP could keep track of all that, we initiated twenty small ALGOL 
programs at once. They all initiated and went to end-of-job just 
fine. That portion, the resource alivcation functions of the B6500, 
is in excellent shape. 


Talking in terms of the frustration associated with delays in the 
product, and delays in the project, as you look back now on where 

we stand from where we stood at the last CUBE Meeting, and where we 
stood at the time we made our initial commitment on delivery and 
performance, we're maybe six to nine months off our schedule, depend- 
ing on how you measure it. Nobody likes that. We're not satisfied 
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with it. I pressure Dent, he pressures me, and we all pressure each 
other. We're doing everything possible to maintain this schedule on 
the good solid basis it is on now. We appreciate your patience in 
sticking with us through all this; and I am sure that when your B6500 
is installed, the wait will well have been worth it. [In spite of this 
wait-and-see period we're going through now, many significant B6500 
orders have been taken since our last CUBE meeting. TI thought you 
would be interested in some of these names. Some are new Burroughs 
users, people that had not had Burroughs computers before, for example, 
the University of Delaware and the Chevrolet Division of General 


Motors. North American Rockwell is the prime contractor on the 
Philadelphia Electric system, and we're negotiating our contract with 
them now. Gleason Works, in Rochester, New York, is also new. We 


are in the final contract negotiating stages, at least I hope it's 

the final stages, with the New York Federal Reserve Bank, and most of 

you, I am sure, have heard of the very large order we recently received 
from Scotland Yard in England. I think those names, along with some 
others, are pretty significant in terms of the impact that the B6500 

is continuing to have on the marketplace. Among our existing customers 
who have placed orders since we last met, are people like Young & Rubicam, 
Johnson Services and the American National Bank, among other customers. 

I think you'll see that the B6500 is continuing to maintain the kind of 
acceptance that it has had since its announcement. 


On the subject of documentation and training, all the major items 
associated with the B6500 have now been formally documented in manual 
form, or in systems notes or in less formal documents from Sales Tech — 
Services and from this department. The big challenge now, of course, 
is to keep those up-dated. There are major PCN's (Publication Change 
Notices ) coming out on all the three language manuals right now. They 
will include discussions of file attributes, for example. The last 
four manuals to be published are all related to the Data Comm Processor. 
We've all been anxiously waiting for these manuals which 
were primarily hung up waiting legal clearance on a lot of things that 
might be classified as inventions. Prior to getting these published 
we had to go through a lot of legal procedures. Those four manuals 

- the Network Definition Language, the Message Control System, the 
Hardware Reference Manual and the Functional Characteristics of the 
Data Comm Processor have now all been published, and I am sure received 
by all of you. The B6500 Operations Manual also has been published. 
Manuals on the other subjects - the Operating System, Hardware Reference, 
etc. - have been out for some time now. The challenge, as I say, is 

to now keep those things up-dated and to cover the system as completely 
as we can from month to month. 


We will also be using Software Assistance Request Forms similar to 
those that are available now for other equipment, and Judy Volk tells 
me that those are either in print now or about to be distributed. 


We're looking now into adopting a mail box technique, or as they call 
them on the B3500 - System Flashes - that supplement systems notes. 


We'll see what kind of a system we can work out to keep systems notes 
current between formal publications of them. 


In order to keep both our own people and our customers well informed, 
we are putting a lot of emphasis on training, both formal training 

in the sense that it will be conducted by people from our training . 
school or from Sales Tech Services or other departments of our Company, 
and informal training in the sense that it is intensive and directed 
toward those people that need it most - the people that have to support 
the installations of B6500's whether they are customer people or our 
own. In that interest, we are currently, I think, in the seventh week 
of a ten week training class in San Francisco, at the Western Region 
site, which is primarily for Burroughs people, and is very intensive 
training - a lot of time on the machine to get those people up to speed. 


During the weeks of May 11 and May 18, we will be conducting a one 

week in-depth training course on the Data Comm Processor. I say we, 

for that includes the training school people, as well as field 
engineering and Sales Tech Services - Bill Brown and Judy Volk's people. 
This is a BMG effort, incidentally, for those customers getting 

systems in the United States, but this, I hope, will be a pattern for 
future classes for our other people and for other parts of the B6500 
system. They are being conducted specifically for the following people: 


- one person who is a Burroughs Systems Rep at the site of 
a system scheduled for this year; 


- a field engineer from that site; 
- and a customer systems person from that site. 


Those three people, representing each of the expected twenty systems 

to be delivered to BMG customers during the balance of this year, are 
the students. We'tll have ten sites represented in one class, and ten 
in the other. This will be in-depth training on the use of the Network 
Definition Language, the generation of DCP code and the role the data 
comm controller plays within the operating system in communicating 
with the Data Comm Processor. The emphasis will be on hands-on 
experience, workshop sessions to get people as well prepared as possibtec 
for their B6500 installation. So, naturally, the emphasis is going 

to be on bringing people into those classes who have the kind of 
experience and background to move quickly along in discussicn of the 
Data Comm Processor and its functions. This, as I say, will seta 
pattern for future training that we hope to keep up in preparing people 
in a very realistic way for their B6500 installations. The Regional 
Tech Managers - Bob Kirsammer and Ren Cherven - are in contact now with 
the. various Branches that are involved to line up the people that will 
be attending those classes. We have developed the B6500 to the point 
now where this kind of training is possible and feasible, and we're 
able to do it and get across the kind of material that is required. Up 
to this point, it was difficult to sit down and handle a class or a 
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training session that covered in depth a subject that probably wasn't 
well documented enough, or decisions weren't finalized to the point 
that good meaningful training could be performed, but we're beyond 
that point now in the complete B6500 story so the training will really 
be intensified from here on. : 


They're scheduled to get a DCP in Detroit in May. We're not going to 
hold up the class in the event that that delivery isn't made on time 
or it doesn't come up quickly or any number of things, for we do have 
the ability on the B6500 to work with the Network Definition Language, 
the Assembler Generator and do everything right up to executing the 
Data Comm Processor cole itself. When I say hands-on training, IT mean 
that the minimum that will be involved will be working with the Network 
Definition Language, describing your terminals, how you set up for the 
number of lines that you have, and, in general, getting as much 
knowledge as possible of the DCP functions. Of course, if the DCP is 
there, so much the better, but this kind of training is needed badly 
enough that we don't want to wait on that kind of eventuality. There 
is a DCP installation scheduled in the Month of May for Detroit. 


Of major interest, certainly, is the status of the B6500 Software. 
Currently, we're operating on a system tape called Mark 1.1. This tape 
has all the basic batch processing capabilities of the B6500 with 

some missing MCP intrinsics and some basic functions, like Sort for 
example. The system that has been in use in the field has contained 
basically the operating system with most of its functions, such as 
Printer Backup and Load Control, all the monitor statements for ALGOL 
and COBOL, the syntax checker for the Network Definition Language, a 
fairly complete group of SPO messages for operator interaction, the 
ability to DS a program for example, to inquire about files, job mixes, 
status of programs - that type of thing, and, as I said earlier, good 
multi-programing capability. 


The principle features that will be added with the distribution of 
Mark 1.2 are the following: First of all the Sort intrinsics will 
work for both ALGOL and COBOL on both magnetic tape and disk. 


This function has been checked out in the Plant, but, of course, Sort 
is one of those things that never really get shaken down until its 
used in a customer environment. We feel that the Sort intrinsic has 
been checked out to as great a degree as is possible in Pasadena. The 
second major inclusion on this tape will be double precision arithmetic. 
This had been delayed awaiting some hardware changes to correct some 
errors that were data dependant. In other words, there were a number 
of data sensitive problems that had to be corrected in the hardware 
circuitry of the B6500. The code has been present for some time, and 
that's being checked out currently in Pasadena for inclusion ‘on this 
next system tape. 


Incidentally, when we go through a routine like this involving both 
hardware and software development, we have close coordination between 


the Field Engineering Technical Operations group in Pasadena and the 
software development people. The objective is that a week prior to 

the delivery of a new systems tape the hardware changes required in 

the system to work with that tape have been distributed and installed. 
On this particular distribution, we're running kind of neck and neck, but 
the plan is that, as of today, these changes which involve some changes 
on circuit cards in the system have been identified, have been released 
to field engineering, and are in the process of distribution. By the 
time the system tape arrives at the various B6500 sites, these changes 
will have been there so that those users will be able to operate with 
the Mark 1.2 system tape. 


The way we handle this in Pasadena is that one B6500 system, number 

102, is used primarily for engineering development. For example, the 
hardware fixes to add double precision arithmetic ability were checked 
out on #102. When the corrections have been verified, they go through 
the industrial engineering route and are installed in system #104, also 
in Pasadena. When the changes are installed and the system tape works 
on system #104, we have, in effect, simulated distribution to the 

field. We have put the stamp of approval on that change in the hardware, 
and then distribution is made through field engineering to the field 


sites in time for use with the new system tape. 


The third principle addition to the Mark 1.2 tape is inter-program 
communication - things that allow a program to start or stop another 
process, to pass direct files and parameters between programs, to 
allow the system and user to do direct I/O operations, and provide the 
ability to communicate between ALGOL programs and COBOL programs. 

This will handle the variables, file identifiers, events, task desig- 
nations and locks. Aliso this wiil include run-time binding as part 

of this inter-program communication function. A major additon, and 
one that Ben Dent just informed me of this morning, which will be 
included with this distribution, is the co-routine functions. Co- 
routines allow two processors to communicate directly with each other 
from their stacks. This is a fast facility of inter-program communi- 
cation which is used primarily by us in the MCS portion of the data 
comm software that will be our standard handler functions. This is 

a very significant inclusion on this new system tape. These functions 
of inter-program communication and binding wiii be discussed as part 
of a presentation at 8:30 tomorrow morning by Jim Oma. 


We'll also be including, not on this system tape, but as a first 
patch to go out to that tape, free field I/0 for both ALGOL and 
FORTRAN. This function is not ready for distribution with the system 
tape, but it has been identified as the first patch that we will be 
sending out. 


Also the following functions in ALGOL - some of which were either 
partially or wholly included in Mark 1.1 - will be present in Mark1.2: 
Picture Declarations, File Attributes, Task Processors, Hardware Events 
and Read Reverse. 
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For COBOL, the ACCEPT VERB, Direct Hardware Name, DUMP and MONITOR, 
SORT, USAGE IS EVENT, CLOSE REEL, LABEL RECORDS, CLOSE WITH PURGE; 
will be present in the Mark 1.2 system distribution. 


Now, at 3:30 P.M. today, there will be concurrent language sessions 
for ALGOL, COBOL and FORTRAN - all three of those. At that time, of 
course, the subject of language implementation on the B6500 will be 
covered in detail. We'll have representatives from both Pasadena 
and from Sales Tech Services in Detroit. These, I believe, will 

be panel discussion type meetings. 


Now in terms of binding, we've really done the hardest part first. 

The run time binding includes all the more difficult features that are 
required for this bringing together of various processors. Much of 
the coding and systems work that has been accomplished to make run 
time binding and co-routines available in this system tape will be 
used in the development of compile time and explicit binding on the 
following tapes. We expect that those will be ready definitely by 
the June tape. It is possible that they could be ready prior to that, 
but the indication now, a conservative one, is that it looks like 
June. Again, this will be discussed in detail at the MCP session 
tomorrow morning. 


So, basically, Double Precision, Sort, and inter-program communication 
are the major additions to this new Mark 1.2 systems tape. This 

should allow us to perform all batch operations on the B6500 - virtually 
everything except data communications. 


' The status of data comm on the B6500 is as follows: On the Mark 1.1 
tape, we're able to do syntax checking of Network Definition Language 
input. On Mark 1.2 we will still have that capability. We will 

also generate, as the NDL compiler does, two files to Disk, one is 
called the shadow file, the other, the network information file. 

The network information file is input to the assembler generator, which 
generates the object code for the Data Comm Processor. All of this 
will be possible on the Mark 1.2 tape. If you had a Data Comm 
Processor on your system, you would input a DCO message to the SPO, 
which would call the Data Comm Processor initializer. This loads 

from disk to core the code associated with the Data Comm Processor 
function. It sets up queues and a message interface, and activates 

the Data Comm Processor. All this, now, has been done in Pasadena, 
where we have three DCP's in engineering use. We have currently tested 
completely, from a hardware sense, communications between TC500's 

and teletypes, multi-drop lines included, on the TC500. We are, this 
week, doing type testing which will include polling and communicating 
between multiple lines on a DCP and multiple stations on a single line. 
All of these things are being done in various combinations with both 
TC500's and teletypes. As you can see, we have closed the loop. 

All the links are in between the central system of the B6500 and the 
terminal network. Some of these are incomplete. For example, the 
operating system for the Data Comm Processor works because it has to 

be there to monitor the execution of the codes that handle a particular 
terminal, but it is incomplete. The data comm controller works, the 
MCS works. All these functions are performing in an incomplete 
preliminary sense. The estimate, especially now that the co-routine 


function is available, is that by June we 1e cor 
communication software package. That could possibly be a little 
earlier, but, being very realistic and conservative, as we always 
are, I would say June. 


will have the 


Again, on 10:30 A.M. Thursday, there will be a session on the B6500 
Data Comm Processor. Pete Nordberg will give a presentation covering 
the basic functions of the DCP for those of you that aren't that 
familiar with it. That will take a brief portion at the beginning 

of the session. Then, between John Kessler from Pasadena and Pete, 
there will be a discussion and a question and answer session on the 
DCP system. 


Here are some other items to complete the B6500 status picture: PL-1 
is now going through syntax checking, and we expect to have that 
completed by year-end. It will be IBM compatible, and a two pass 
compiler, similar to our approach on the COBOL compiler for the B6500. 
Dual processors will be installed in Pasadena for system testing in 
May. We have a couple of dual-processor installations now - one is 

at Barclays Bank in London, the other is currently going in at Fort 
Meade. We haven't released the software for that yet, but this simply 
requires checking out of the code that's already there to handle a 
multi-processor system. 


Bulk core, of course, is an unannounced product for the B6500. However, 
the independant functioning of memory modules, the basic design of 

the system, the fact that each module has its own internal logic, 

its own address recognition circuitry, and so forth, means that we 

can do quite a bit with a lot of flexibility in the use of bulk core 

as either a directly addressable memory or as an auxiliary memory 
device. We will be making an installation of a directly addressable 
buik core, this summer at the University of California at San Diego. 
This is part of their request to do some software experimenting on 
their own. 


The Disk File Optimizer, which was formerly called the Queuer, is now 
being tested in Pasadena. It's scheduled for field test this summer 

at the Illinois Secretary of State Installation, and customer deliveries 
will begin in November of this year. We expect that this will provide 
an increase in disk performance of some 10 to 20 times for a heavily 
used disk file subsystem. 


Multiple SPO's are working. I believe the Barclay system has multiple 
display devices for SPO's on it. I don't know of others - although 
there may be one or two by now. The major emphasis on the following 
system tape - the May tape - will be on this general subject of a 
man-machine communication - SPO messages, logging, etc. Incidentally, 
there will be a session here at 3:30 Thursday, on B6500 logging and 
other operator interaction. 


On Timesharing, we are planning that about nine months after the 
basic data communication software is completed, which would put us in 
the first quarter of next year, we will have included within the 
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B6500 operating system the timesharing function, primarily identified 
by the way in which it handles memory allocation within the system. 


The Terminal Software schedule, in other words, the development of 

DCP Software for the various terminals that will be used on the system, 
has been set to coincide with customer demand. Those terminals that 
are being shipped already, of course, will be the ones that will get 
the earliest attention, such as the TC500, the input and display 
device, teletypes, B300 systems, IBM 1030's, IBM 360's the DC1000 

and the automatic calling feature. These are the close-in units 

that are scheduled for development of DCP code. Once the basic 
software is completed, which it just about is, the development of 
individual code for various devices is not a large project - one man for 
about a week or two, is the estimate. 


For Application Software, Wayne Nelson and members of his department 
will be covering various application software packages in other 
sessions here, I'll just briefly give you a schedule of availability 

as it stands now. Of course these dates are dependant on the system 
software being operational so they can get down to the final debugging 
and checkout of their applicational packages. First of all, Disk FORTE, 
or equivalent system to the Disk FORTE on the B3500, will be available 
in September on the B6500. Phase 1 of the Data Management System, 

of which FORTE can be considered an interim step allowing you to. work 
on your file organization and get your inter-relationship of files 
defined for the B6500 Data Management System, will be operational 

in March of 1971. This will include the Data Definition Language, 
Systems Control Language, with the fill capability equivalent to Disk 
FORTE, a directory structure and an audit trail capability. Those will 
be included in the first phase of data management. At 3:30 P.M. 
tomorrow Shree Bedekar and Roy Guck will cover the status of a Data 
Management System on the B6500. 


The BASIS package, equivalent to level of 2.6, is scheduled for 
availability on December t of this year. The ALPS package, the Linear 
Programming as it exists on the B5500, will be available August Ist 

of 1970. The BIP system - the Integer Programming system availability 
is September 15% of this year. DYNAMO, September 15 as well; SIMULA 
1, January 15 of 1971; the GASP system - that's another simulation 
language - October 1st of this year; and the problem oriented~-language, 
known as POL, will be September ist of 1970. 


Most of our attention is quite naturally devoted to engineering 
development of the B6500 as a product. For a moment, though, consider 

the fact that the kind of modularity that we build into the system, the 
Hallmark of the B6500 design and of our large system design in general, 
and with it, the dynamic modularity that's available - the ability to 
change configurations quickly and have a responsive machine - put 

quite a bit of pressure and a tremendous responsibility on our manufactur- 
ing capabilities. Once the system has been designed then it's up to 
someone - a manufacturing group - to produce those computers at the 

rate we talked about earlier. So you combine this characteristic 
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with the extreme flexibility provided to allow you to configure the 
B6500 in virtually an unlimited number of configurations, and you can 
begin to appreciate the challenge presented to the manufacturing side 
of the picture. So what I'd like to do this morning, then, is take 

a few minutes to describe to you very briefly how we manufacture the 
B6500. We've really got to take job shop skills required to customize 
a single order, and combine that with the ability to operate ona 
production line basis. 


If you were to go out to Pasadena right now, and more specifically to 
the Proctor or Large Systems Plant, which is some five miles from the 
Pasadena Plant, you would see that we have more space there dedicated 
completely to the B6500 than the total Pasadena Facility. Some five 
to six-hundred thousand square feet of area are devoted primarily to 
manufacturing. Engineering is in still another wing of the Plant. 
The manufacturing of the B6500, from the circuit card right up to the 
final product will be wholly contained in that Proctor Facility. Just 
prior to your system leaving the shipping dock, it will have gone 
through a three-week system test period. The whole central system of 
your B6500 will have been put together in the same configuration that 
you would have it at at your installation, and will have gone through 
a rigorous system test. This system test wili be done by our quality 
assurance people and by your field engineers who will be there riding 
out the system in its final stages. 


We'll have six of these system test stations set up. A machine will be 
at one of those sites for three weeks of testing prior to final shipment. 
So that's sort of the job shop aspect of the production of the B6500. 
Prior to that, however, various components will have stayed up to five 
weeks at unit test stations. For example, an I/O Multiplexor will 
spend five weeks at a unit test station connected to the balance of a 
B6500 configuration which is there to check out your multiplexor. The 
Central Processor is at another unit test station for a matter of three 
weeks being fully tested with the balance of a B6500 system that had 
been tested and proven out previously. The Data Comm Processor will 
have two weeks of such testing, and Memory Module cabinets, three weeks. 
We are currently building this up at Proctor as the space becomes 


available or as the Plant becomes operational. We have one of each of 
these unit test stations in operation now. We will build to a total 
of eighteen of these by the end of this year. This, of course, puts 


added burden on our manufacturing schedule because that represents the 
equivalent of another eighteen systems being manufactured to stay right 
there at the Plant serving this unit test function. Eight of these will 

be Multiplexor test stations; five of them Processor; two, Data Comm 
Processor; and three, Memory. The number of test stations is proportionate 
to the amount of time each component has to stay in the station. 


Three weeks prior to the beginning of the unit testing, a factory order 
is released to the factory floor describing a given system. For example, 
the systems that were shipped last week would have gone through a 
fourteen week period beginning with a factory order release to the 

floor saying these are the parts required, for example these are the 
cards required for the cabinets that make the 17,0, Davis svstem. 
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The first step along the way is to get the card kit put together for 
the system that's going out. The second step is the cabinet assembly. 


This is the production line part of it. You can see out there in 
Proctor a conveyor belt that runs along the ground where a cabinet 
comes down. When it starts, it's empty, and as it passes a set of 


lines that run perpendicular to this assembly line, various parts are. 
being taken off and put into these cabinets. So at the end of the line, 
a completed cabinet, ready for a given configuration, is done. It 

then goes directly to a unit test station and the unit testing begins. 
Finally comes the system testing, as I said earlier, and then the 
fourteen week cycle is completed and the system is ready for shipment. 


For those of you receiving systems in the near future who would like 
to get out to Proctor, I would like to encourage you to go there. We 
have a part of my. department located in Pasadena now, and they will be 
moving to Proctor as soon as. the office space is done. This is under 
the direction of Bob Johnson, Manager of Systems Evaluation for Large 
Systems Sales. I would say that some two, three, four weeks prior to 
your delivery would be a good time to schedule such a visit and get a 
good tour of the Proctor Facility. I think you will be very impressed 
by the fact that a real manufacturing operation, as well as a comple- 
mentary engineering function is there to assure that your systems get 
out on time and in good working order. 


I think some trends in the orders for B6500's would be interesting to 
you. With the B5500 this has been true, I guess, for the last two and 
a half years, one-third of all installations have been dual-processor 
systems. Just about half of all B6500 orders are with dual-processors. 
Again, talking about our unique capabilities in the computer industry, 
this is really an unproven concept for a general operating system . 
anywhere else in the industry. Yet, here's the B6500 with half of its 
orders for dual-processors. 


The B5500, of course, has a maximum of 32,000 words of memory, so far, 
and virtually every B5500 installed now has the maximum eight memory 
mods. 


On the B6500, the average configuration is just under the five memory 
mod figure ~ 81,000 words. So every B6500 has four, five or more mods 
of memory on it. 


The average rental of a B5500 is about $30,000 a month. For the B6500, 
the average rental of all systems on order is now $67,000 per month per 
system. So if you take the number of systems on order and annualize 
the rental figures, you come up with an annualized revenue associated 
with the B6500 as the order picture stands today of some forty million 
dollars per year. This, of course, will build up as deliveries and 
orders build up. All this means that you're pretty important to the 
Burroughs Corporation, and I hope that we will treat you accordingly. 


To make sure that we keep up with the increasing demand in manufactur- 
ing and deliveries, we're continuing to do a lot of automation in terms 
of both the manufacturing and the ordering cycle. We began with a 
program developed by Bob Johnson's group which allows an account manager 
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or customer to sit down at a B5500 terminal and configure his B6500 
without worrying about prices, model numbers or the right number of 
controls. Using this program, every B6500 order is configured correctly 
according to the price book and the configuration rules. Back at the 
Plant, another automation process is. in the debugging stages now to 
take the factory order that's generated from the sales order for a 
system and automatically configure the more detailed description of the 
system - the cable lengths, the number of sides per cabinet, how it is 
structured, the number of peripheral controls and the various parts 
that go into them. All this is done to give us the ability to handle 

a much larger number of orders than we have handled previously. It 
eliminates the kind of errors that have happened when this is done 
without the benefit of automation. 


Before I wrap this up, I would like to give you a little coverage on 

the B5500. There's a concurrent session going on next door, and, of 
course, I guess most of you have representatives over there. Very 
briefly, let me say that although a lot of our emphasis is on the 

B6500 right now, there is continuing emphasis on the B5500 program, 
greater than there ever has been. A new organization has been set up 

in Pasadena under the direction of Brad McKenzie as Program Manager. 

He has, under him, three groups: (1) Programing Systems & Development, 
which is headed up now by Al Rabenau (his place in Sales Tech Services 
for Large Systems, incidentally, was taken by Bob Brown, who I'm sure 
all of you will get to meet before this session is over). (2) Systems 
Advancement & Project Control, under Ira Purchis; and (3) B5500 Hardware 
Engineering. A large number of people comprise these three groups 

whose primary purpose is to extend the already amazing life of the B5500 
product. This will be done by not only continuing to improve the exist- 
ing system, but by coming up with some additions and new departures in 
the design of various functions on the B5500. 


Due for customer distribution in June will be the Mark 11 MCP for the 
B5500. I'm not going to go into any detail on this because that's 

the purpose of the other session, but this system will allow the MCP 

to reside in user disk, and will have improved library maintenance 
features, faster halt/load initialization and improved directory search 
techniques. The shared disk software will also be on that tape, along 
with improved disk allocation. 


On the Timesharing MCP tor the 55500, there wiii be many improvements 


also - TYPE "Data" files, extended resequencing options, extended copy 
options, implementing the RMERGE verb, improved "WHATS" command and 
new "CHANGE FACTOR® construct. So this is just by way of indicating 


that there are continuing improvements to the existing software packages. 


In addition, though, to the existing software, a new COBOL compiler is 
under development that will be available late in the fourth quarter of 
this year. Pass 1 of this compiler, the syntax checker, will be on the 
Mark 11 MCP tape as well. We expect faster compilation, smaller core 
requirements and just a better overall compiler for COBOL. This, of 
course, is the outgrowth of earlier CUBE dialogues. 


aie 


COMPANY CONFIDENTIAL 


There is a session at 3:00 p.m. on Thursday with Mitch Ratuzgnik, on 
the subject of the TC500 and the input and display unit on the 
B5500. That software will be ready for field test next month also. 


By the middle of July, we expect to have (at least to Sales Tech 
Services) the software for the timesharing system version of the B6500 
Data Comm Processor on the B5500. We'tre stiil readying the release of 
that product, along with the extended core memory and the shared disk 
capability. These features will be available in the third quarter of 
this year. I'!11 just give you some rough indication of pricing on them. 
Shared disk, when you include the standard number of options to incorp- 
orate it, will cost about $2,000 per month. The Data Comm Processor 
will have a break-even point using existing hardware, that is, the B487 
terminal and adapters, at about 24 lines, which means a price of $2500 
to $2600 per month. Auxilliary memory - the using of core memory on the 
drum hubs - is in field test at Barclays Bank. The pricing on that one 
is being worked out right now. 


The availability of these three 
features will be about the third quarter of this year. These, along 
with the new COBOL compiler and further enhancements to the timesharing 
system, I think provide pretty good evidence that the B5500 still has 
a long and fruitful life ahead of it. 


A lot of times we get kind of frustrated by the emphasis we think ought 
to be put on evaluating equipment, trying to determine just how good a 
B6500 or a B5500 is and how we can make it better. I guess we've given 
this more talk than action in the past, but now I think you'll find 
throughout the Burroughs Corporation, a lot of action on that subject 
already beginning on the B6500. We have in Large Systems Sales Develop- 
ment, a Systems Evaluating Group with Bob Johnson as the manager, as I 
mentioned. We're working closely with Pasadena Engineering on measuring 
the B6500, looking for ways to further increase its performance through 
future developments of the product. Engineering has many plans of their 
own, which are not available for release yet, for evaluating products 

in their own manner. Our function in Marketing, of course, is to eval- 
uate the product for our purposes and give engineering some intelligent 
feedback on where we feel enhancements and improvements should be made 
for marketing purposes. 


Computers are the fastest growing part of our company. In Mr. Macdonald's 
report to the stockholders a couple of weeks ago, he mentioned that our 
Company's growth in data processing has tripled in the last five years, 
and, of course, large systems is leading the charge in that area. S50 

this is really the most important part of the Burroughs product line. 
We're maintaining an increase in marketing activities within this depart- 
ment and within the whole Burroughs organization. 


We have an interesting session at 7:30 p.m. tonight on the subject of 
Executive Seminars. This was brought up as a request by the CUBE 
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organization as a way of developing some ideas on presenting Burroughs 
products, presenting our equipment and techniques to higher management 
within your Companies. So we're going to talk about tools that will 
help you sell to your management, as well as help us sell to executive 
management of prospective customers. I think you will be pleasantly 
surprised by the kind of thought and the kind of development that has 
gone into this kind of executive seminar approach, so we're looking 
forward to that meeting with you. 


That pretty much covers the Large Systems Status Report. I just want 

to say that there's no doubt about the performance of the B6500 today, 
its' acceptance in the marketplace, or that Burroughs will be the 

large systems manufacturer of the future. There are a lot of large 
computers around - big fast computers - but it's surprising to see the 
reactions wetre getting from some of our competitors who are wondering 
where the marketplace is for this type of system. We feel, and we 

have felt for quite a number of years now, that the marketplace for 

large systems is in data processing. Even the scientific large system 
user has a lot of data to process, and he's got to get at data effectively 
so that when it comes time to combine those numbers together, the numbers 
are there to use. Our system design - our approach - has been thoroughly 
accepted by the marketplace. I'm very confident that a few years from 
now we'll be THE leader in large systems, and certainly, right now, we're 
one of the big four in large systems marketing. Of course, that's more 


your success than ours, really - your acceptance of our product has made 
this possibile. 
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